Generally, diversification of data class to deal with may produce a difference in data items to be managed for every data class in data management. For example, if the class of product is diversified when managing product data, since the data items of the product managed in connection with this will be diversified, it is necessary to manage various data items for every goods kind.
When dealing with a plurality of the product data having a wide variety of product features with difference in the data item to be managed using a computer device, there is a method of managing the product data of all classes generated during a transaction using one record format. In this case, since the data item required for all products is set up beforehand, it may just refer to one database for the operating program which processes product data.
However, a record format which defines a data item need to be changed whenever change in product class or a data item arises, if the product data of all classes is managed using one record format, and a problem with complication of work for changing such change is expected. Even if it is the data item used only for a specific product, a region must be secured as a data item of all other products, and there is a problem that a memory region cannot be used effectively as a whole.
In order to solve such problems, there exist the following conventions technologies such as (1) and (2). In addition, the following conventional technology (3) exists as the case in which plural classes of products which have the various product features are dealt.
(1) Product class codes for specifying class of product and product content codes for identifying content of product are recorded in transaction data, and a product management table in which product contents corresponding to the product codes are classified in a plurality of data items and stored is created for each product class. A business application program for processing the transaction data specifies the product management table in accordance with the product class codes and further acquires each of data items as the product contents in accordance with the product content codes.
Consequently, what is necessary is to change only the product management table, even when there are some changes on the product class. Similarly, it is necessary to change only the product management table even when data items on the product management table have been changed. In this way, no change is required for the record format of the transaction data.
FIG. 18 illustrates an example of the conventional technology (1) described in the above. A is transaction data managing insurance contracts by which data of policy number 1801, of insurance premiums 1802, of insurance period 1803, of clause code 1804 and of types 1805 and so on are managed. In this case, the clause code 1804 is data for specifying a product class of an insurance product. B is a table (a whole life insurance table) managing data item of “whole life insurance” that is product content corresponding to the insurance product whose clause cord 1804 is “001”, and also manages data of step payment period 1807 and of step payment ratio 1808. C is a table managing (annuity insurance table) data item of “insurance annuity” that is product content corresponding to insurance product whose clause code is “0002”, and also manages data of annuity class 1811 and of annuity payment class 1812 for each type 1809.
Hence, even if it is the case where a new insurance instrument is additionally introduced by preparing the managing table which became independent every clause code 1804 which is a product code, and constituting so that the content of the product of the management table can be specified in accordance with the type 1805, additional creation of the product managing table corresponding to this can be carried out, and change of a record format of the transaction data can be avoided.
In an insurance product management system, there exists a case in which a desired product information is acquired by recording a basic key commonly used for products and sub-keys each having difference in meaning for products on a product information table and by conducting a search for the product information table in accordance with the sub-keys in a program by which products are handled (see patent document 2, for example).
(2) The data related to the data item corresponding to a desired product class is acquirable by establishing free definition items into the transaction data and by redefining formats within the free definition items for each product class.
Consequently, change in the system can be done by just varying the method of redefining the free definition items even if it is the case where change arises in the product class.
FIG. 19 illustrates an example of the conventional technology (2) described in the above. A is transaction data managing insurance contracts by which data of policy number 1901, of insurance premiums 1902, of insurance period 1903, of clause code 1904 and of free definition item 1905 and so on are managed. In this case, the free definition item 1905 is an item for redefining and using a product content related to the insurance product specified by the clause code 1904. B is a part of a COBOL (Common Business Oriented Language) program for redefining and using the free definition item 1905. In other words, with the program, data responding to the product class corresponding to a desired clause code can be handled by defining the free definition item 1905 as a FILLER item of X(100) and then by defining the FILLER item for product class using a REDEFINE clause (see non-patent document 1, for example). A redefining description 1911 is for redefining data of its product class “whole life insurance” and similarly another redefining description 1912 is for redefining data of its product class “annuity insurance”.
Thus, even if it is the case where a new insurance product is additionally introduced, by constituting so that the free definition item may be redefined every clause code 1904 which is a product class, the redefinition description corresponding to this can be added and change of a record format of the transaction data can be avoided.
(3) A system in which a data value of a desired data item in a desired product class is acquired by creating a product database respectively defining data items to be handled as constituent elements and by carrying out operations such as switching one of the product database used in a business application program implementing processing the product data and the database into which data related to the constituent elements is recorded, is known to the public (see patent document 1, for example).    [Patent document 1] Patent laid-open publication Hei10-334160    [Patent document 2] Patent laid-open publication Hei08-329142    [Non-patent document] Pages 143 to 145 of “Introduction to COBOL” published on Apr. 1, 1993 by OHMU Publishing under collective writing of NISHIMURA/UEMURA
In the conventional technology (1), however, it is necessary to newly provide a managing table in the case of adding product class and also necessary to change the format of the managing table when data item of the product class is changed. In this case, the operator needs to set up each of the types while ensuring consistency on each of data contents among each of data items managed at the managing table for each product class.
For example, D shown in FIG. 18 is a table (prescheduled interest-rate sensitive annuity insurance annuity table) managing data items of “prescheduled interest-rate sensitive annuity insurance” that corresponds to an insurance product whose clause cord 1804 is “003” and data of annuity class 1814, of annuity payment period 1815 and of ratio review period 1816 are managed for each type 1813. When the prescheduled interest-rate sensitive annuity insurance annuity table is added, the operator carries out operations in accordance with the annuity insurance table having similar data items. Specifically, the prescheduled interest-rate sensitive annuity insurance annuity table D is obtained by adding a line of the ratio review period 1816 to the duplicated annuity insurance table C.
It is assumed that there exist two kinds of data for the ratio review period 1816 such as “review every 5 years” and “review every 10 years”. In this case, the ratio review period 1816 can be added to each of line record of the duplicated annuity insurance table C. The operator, therefore, needs to set up the type 1813 corresponding to each of the line records while ensuring consistency on each combination of the annuity payment period 1815 and ratio review period 1816. Such additional work on the managing table requires great amount of attention as well as work, so that the work become unexpectedly complicated.
In the conventional technology (2), there exist a problem that the maintenance-ability of the business application program decreases during addition/alteration work of product class because a huge amount of alteration work is required based on the differences in product class in the business application program which handle the transaction data.
For example, as shown in FIG. 19, it is necessary to add another redefining description 1913 on the prescheduled interest-rate sensitive annuity insurance while adding judgment logic where the article code 1904 represents the prescheduled interest-rate sensitive annuity insurance. Further, a processing logic on the product features in the case of dealing the prescheduled interest-rate sensitive annuity insurance is need to be added. In addition, a system testing needs to be conducted by re-compiling the COBOL program after these works. The maintenance-ability of the business application program decreases because those works on the business application program are still required.
In the conventional technology (3), the formats under transaction need to be changed for each product class because the combination of the constituent element used for every product class differs. As a consequence, unification of the transaction data becomes difficult and there is a problem that a system configuration is complicated.
An object of the present invention is to provide a data management system capable of (1) doing a system change without imposing a heavy burden on the operator, (2) avoiding decrease of maintenance-ability of the business application program and (3) making unification of the transaction data easy and making the system configuration simple.